IP Multimedia Subsystem (IMS)
IMS is defined by 3GPP as a new subsystem, i.e. a new mobile network infrastructure that enables the convergence of data, speech and mobile network technology over an IP-based infrastructure.
IMS was designed to fill the gap between the existing traditional telecommunications technology and internet technology that increased bandwidth alone will not provide. This will allow operators to offer new, innovative services that shareholders and end users are expecting.
IMS was specifically architected to enable and enhance real time, multimedia mobile services such as rich voice services, video telephony, messaging, conferencing, and push services. IMS is designed to enable these user-to-user communication services via a number of key mechanisms including session negotiation and management, Quality of Service (QoS) and mobility management. However, IMS enables much more than just real time user-to-user services.
The mobile industry is in a transition phase from traditional voice and short message service centric business to a variety of new and exciting multimedia services and applications. Telephony and messaging is about to be complemented by the next generation of person-to-person applications, making sharing easier—two-way radio sessions (Push-to-Talk), sharing a view, sharing files, shared whiteboards and multiplayer game experiences. It also brings the ability to combine existing services in exciting ways, for example when adding a multiplayer game during a Push-to-Talk session.
The IP Multimedia Subsystem (IMS) does not only encompass its deployment in cellular/wireless networks (such as 3G networks—see for exemplary purposes 3GPP TR 23.228 “IP Multimedia Subsystem (IMS); Stage 2”, V. 7.2.0, available at http://www.3gpp.org) but also enables new services between mobile and fixed devices. Examples of such services can be content sharing or messaging services between a mobile terminal and PC.
Push-to-talk Over Cellular (PoC)
One of the services utilizing the IMS infrastructure are Push-to-talk applications like Push-to-talk Over Cellular (PoC) that is developed and standardized by the Open Mobile Alliance (OMA).
Push to talk over Cellular (PoC) provides a direct one-to-one and one-to-many voice communication service over cellular networks. The idea is simple. Thanks to PoC's ‘always-on’ connection, users can make calls to individuals or groups at the press of a button. The availability of other users can be checked before the call with the help of the presence function. The call connects almost instantly and the receiver doesn't even have to answer. Users of push to talk services are often engaged in an activity other than a telephone call and can stay informed by listening in to group traffic while they are busy. A user can also be contacted by name or may occasionally want to say something to the group. PoC is based on half-duplex Voice over IP (VoIP) technology, using an IP-capable network, i.e. one participant can speak at a time while the other participants receive the voice data
Push to talk is not a substitute for any existing cellular service. It is a complementary service that allows operators to develop and differentiate their voice portfolio without having to change their existing services.
The OMA PoC standard network architecture is based on a PoC application server (PoC AS) connected to the IP Multimedia Subsystem (IMS) as exemplarily illustrated in FIG. 10. The IMS takes care of common functions, such as user authentication, call routing and generic charging based on the Session Initiation Protocol (SIP).
For further reading it is referred to the OMA website http://www.openmobilealliance.org, especially to the OMA drafts “Push to talk over Cellular (PoC)-Architecture”, Candidate Version 1.0, 27 Jan. 2006 and “Push to talk over Cellular (PoC)-Architecture”, Draft Version 2.0, 14 Mar. 2006 (available at http://www.openmobilealliance.org)
The PoC application servers handle application-specific tasks such as floor control (the reservation of talk spurts for one speaker at a time). They also provide interfaces to the operator's provisioning and network management systems and create application-specific charging detail records (CDRs). The push-to-talk user database contains provisioned users and their service profiles. The users and talk groups can be arranged in the database in organization-specific closed user groups to support the security and administration capabilities needed in business applications. The push-to-talk solution can be scaled up to multimillion user networks with several networked PoC application servers.
As indicated in FIG. 10, various cellular access networks may be used to distribute the PoC media data to the PoC users. The cellular access networks are also referred to PoC enablers. Examples for PoC enablers are 3GPP networks, GSM networks or 3GPP2 networks. Architectural requirements for 3GPP networks as PoC enablers can be found in 3GPP TR 23.979 “3GPP enablers for Open Mobile Alliance (OMA); Push-to-talk over Cellular (PoC) services; Stage 2”, V. 6.2.0 (available at http://www.3gpp.org).
The push-to-talk service is based on multi-unicasting. Each sending client sends packet data traffic to a dedicated push-to-talk server and, in the case of a group call, the server then duplicates the traffic to all the recipients. No multicasting is performed either in the access or core network and the mobility management is carried out by the radio network. This is why the push-to-talk solution works transparently over the cellular and fixed networks. PoC call control and other signaling is based on the IETF-defined SIP and voice traffic is carried through an RTP/RTCP-based streaming bearer. Mobility is handled through (E)GPRS using support wide-area roaming over GSM/WCDMA.
A PoC solution protocol stack is shown in FIG. 11. On the application level, the PoC applications are provided. For session related signaling, typically SIP is used so as to establish, change or tear down the session. For media transport RTP/RTCP is commonly used. The signaling and transport related protocols SIP and RTP/RTCP are transported by UDP (also TCP is possible) and by the IP protocol. The IP packets are finally provided to the service participants in the different access networks using access network specific channel, such as 3GPP mobile channels.
Potential Problems
The PoC service is based on a conferencing focus, i.e. a central element controlling the communication, which is called PoC Application Server (PoC AS). All participants are connected to this node resulting in a star-topology underlying the PoC service. As one of the main functions, the PoC AS implements floor control i.e. controls the permission to speak. The participant that gained the floor transmits its voice data to the PoC AS, which in turn distributes it to all other participants.
In general the PoC AS is implemented as an application server of the IP Multimedia Subsystem (IMS). Participants of the PoC service can be connected to the PoC AS via any IP-Connectivity Access Network (IP-CAN) providing access to the IMS network. This includes GPRS access with a GERAN and/or UTRAN radio access as specified by the 3rd Generation Partnership Project (3GPP).
The deployment of a PoC Application Server as a conferencing focus allows for easy (centralized) control of the service. The group communication is realized using many point-to-point connections. However, for increasing group sizes this point-to-point nature leads to inefficient distribution of the service data. The same data has to be copied and transmitted individually for each participant. This becomes particularly relevant for wireless participants utilizing scarce radio resources to access the service.
As outlined above there is a need for efficient distribution of the group communication, especially considering large group sizes and scarce radio resources. To avoid the Inefficiencies of multiple point-to-point transmission it is obvious to utilize point-to-multipoint transport or multicasting whenever possible.
Regarding GPRS-based IP-CAN to the IMS network this functionality is provided by the Multimedia Broadcast/Multicast Service (MBMS). It establishes a multicast delivery tree in the GPRS core network and utilizes radio broadcast efficiently transmitting data to a large group of users. MBMS is supported in UTRAN as well as GERAN radio access networks.
This utilization of MBMS for IMS services and PoC in particular is recently discussed in 3GPP standardization groups. The issue is tackled in a 3GPP work item and respective service requirements have been defined in 3GPP TS 22.228, “Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1”, V. 7.3.0 (available at http://www.3gpp.org). Further, some technical proposals have been made how to realize MBMS utilization for IMS services. However, the current discussion focuses on the usage of MBMS in a local domain, e.g. inside a single operator's network, which represents only a limited service scenario.
To better understand the invention and the difference to prior art the full service scenario has to be understood. Generally it is possible for IMS services to span different domains, e.g. involving different operator networks. Naturally, this is also possible for the PoC service. To support this inter-domain scenario the PoC AS can take over different logical and functional roles in a PoC call. Either it can perform the Controlling PoC Function or Participating PoC Function, or both at the same time. The Controlling PoC AS acts as the conference focus executing call control, whereas the Participating PoC AS acts as a proxy forwarding signaling and data between the PoC User in its local domain and the Controlling PoC AS in another domain. There is always one single Controlling PoC AS, but there could be many Participating PoC AS, e.g. in different operator domains, present in a PoC call. Usually the PoC AS serving the user initiating the PoC call takes over the role of the Controlling PoC AS.
Although current standardization activities in this field are ongoing and not finalized, it may be assumed MBMS transport functionality to be available for a PoC service. The controlling element of MBMS is the Broadcast-Multicast Service Centre (BM-SC). Utilization of MBMS for a PoC service can be achieved in several ways. A new interface between the PoC AS and the BM-SC could be established allowing the interaction of both (separate) elements. Another way could be to integrate both functional modules into a single element. However, from a functional perspective both options are equal.
The MBMS functionality is available within a GPRS-based IP-CAN, as already stated before. Generally this is under the control of a specific network operator. With respect to the inter-domain scenario outlined above, this results in the situation that support for MBMS transport functionality is a local property of a specific PoC AS, because a PoC call could span multiple operator domains. Therefore, it has to be assumed that MBMS might not be available at all PoC AS involved in the call.
MBMS support in the network is one aspect, which has to be considered for its utilization in a PoC service. Another one is that MBMS reception depends on terminal capabilities. Some terminals might not be able to receive MBMS in parallel to an IMS service like PoC. Others might not be able to receive MBMS at all. Therefore, it has to be assumed that MBMS might not be supported by all PoC users.
The main problem arising in the full service scenario outlined above is caused by the different functional roles of each PoC AS involved in a PoC call. As MBMS transport support is a local property of a PoC AS, the Controlling PoC AS does not know whether the Participating PoC AS utilizes MBMS transport functionality and assumes point-to-point connected users.
Therefore (as indicated already above), the Controlling PoC AS establishes individual connections for each participant to the Participating PoC AS and distributes individual copies of incoming voice data. In case MBMS transport functionality is utilized in the local domain, the Participating PoC AS would forward all voice data received on any connection to the BM-SC. Therefore, all individual copies of the same voice data would be transmitted on the MBMS bearer. As all participants in the local domain receive this MBMS bearer, each participant would also receive all copies of the same voice data, instead of receiving it just once.
On the one hand this unnecessary transmission of voice data copies is of course a waste of resources, especially on the radio interface. On the other hand the reception of multiple voice data duplicates at the terminals cannot be rendered in a sensible way to the PoC users and might cause sever problems in the receiving applications.
The scenario and its potential problems are exemplarily depicted in FIG. 12.
As a conclusion, unnecessary transmission of voice data copies occur                (1) between the Controlling and Participating PoC AS and        (2) in the downlink MBMS bearer of a PoC call.        
Another problem arising in the full service scenario is related to the decision whether to utilize MBMS transport functionality for a PoC call. Although the PoC service enables group communication and MBMS enables efficient distribution of data to a group of users, it might not be sensible in all cases to use available MBMS transport functionality. Due to its properties, especially on the radio interface, there is a trade-off regarding efficient data transmission and resource consumption for MBMS.
Therefore, it only makes sense to use MBMS transport for a large or dense group of users. In this respect, it is important to have accurate group information available as a basis for the MBMS decision at the PoC AS. This is the case for the Controlling PoC AS, which receives complete group information in the request from the initiating PoC user. But this is not the case at the Participating PoC AS. Here the group information has to be derived from separate signaling messages, which might complicate the decision on MBMS utilization for a PoC call.